feat(mtda-cli): find all mtda agents in give ip pattern#565
feat(mtda-cli): find all mtda agents in give ip pattern#565shikl3x7 wants to merge 1 commit intosiemens:nextfrom
Conversation
This commit is just proposal to start discussions on having a api to search all agents and their status, which would potentially help in automation labs with multiple setups to get the status of agent and use it to deploy. For now i have used the storage_status if the idea seems valid and fit ,would like work and add required apis in main to make this feature more dependable. Signed-off-by: Shivaschandra KL <shivaschandra.k-l@siemens.com>
|
Hi, IMHO this should not be an mtda feature, but instead rely on lava, Netbox or a custom fronted implementation. MTDA can assist by sending mdns broadcasts to make other participants aware of its address / existence. I used MTDA interactively in a larger lab by putting an Nginx as reverse proxy in front of the nodes. The Nginx can also be exposed without providing direct access to the testlab. Example configuration for that was added by me in 1e383d5. With #563 the UI is also almost feature complete, despite it is still tricky to use non interactively as the websocket interfaces are not documented (are not public interfaces). In general, running MTDA in a bigger lab is still tricky due to #562 and #524. Once these are solved, we could even think of a MTDA proxy as dedicated application that just relies data to the correct (and discovered) MTDA device. But this should be a standalone application which is not part of MTDA itself (the same applies to the client as its source code is tightly coupled with the server). |
|
a while back, support for ZeroConf was added. see Line 88 in 0615c47 the feature may need to be documented & tested. |
Shall I change the implementation to use the ZeroConf and propose or shall we use this as part of the of our automation framework and just document here the usage. |
This commit is just proposal to start discussions on having an Api to search all agents and their status, which would potentially help in automation labs with multiple setups to get the status of agent and use it to deploy.
For now, I have used the storage_status, if the idea seems valid and fit, would like work and add required Apis in main to make this feature more dependable.